home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part2 / 15940 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  3.3 KB
  1. Path: news.sprintlink.net!datalytics!usenet
  2. From: Rob Stewart <stew@datalytics.com>
  3. Newsgroups: comp.lang.java,comp.lang.c++,comp.lang.smalltalk
  4. Subject: Re: Will Java kill C++?
  5. Date: Mon, 08 Apr 1996 16:48:08 -0400
  6. Organization: Datalytics, Inc
  7. Message-ID: <31697B88.F7C@datalytics.com>
  8. References: <3134D499.653E@ix.netcom.com> <313613B2.136E@ksopk.sprint.com> <4i7qhl$ik6@cronkite.seas.gwu.edu> <4iuhi7$fmf@sundog.tiac.net> <4iumap$mn5@hustle.rahul.net> <31582A45.3742@vmark.com> <3163C031.4FB1@esec.ch> <3164888D.2B01@concentric.net> <4kbfn8$1bu@news1.is.net> <316971B0.FEF@amd.com>
  9. NNTP-Posting-Host: 204.62.224.71
  10. Mime-Version: 1.0
  11. Content-Type: text/plain; charset=us-ascii
  12. Content-Transfer-Encoding: 7bit
  13. X-Mailer: Mozilla 2.0 (WinNT; I)
  14.  
  15. Paul G. Schaaf, Jr. wrote:
  16. > 
  17. > Mark VanTassel wrote:
  18. > >
  19. > > "Alan L. Lovejoy" <alovejoy@concentric.net> wrote:
  20. > >
  21. > > >Bzzzt!  Not according to the benchmarks I've done.  Go benchmark the
  22. > > >factorial or fibonacci functions (implemented recursively) in both C and a
  23. > > >good Smalltalk.  You are in for a big surprise.
  24. > >
  25. > > You're not seriously suggesting that a fibonacci series be programmed
  26. > > recursively, are you???
  27. > 
  28. >    Read again what he said.  He is suggesting an experiment to test the speed
  29. > of recursion; not declaring viable implementation for Fibonacci.  But perhaps
  30. > you are correct in attempting to make this explicit for other readers:  DO
  31. > NOT USE RECURSION TO IMPLEMENT FIBONNACCI for anything other than
  32. > experimental purposes.
  33. > 
  34. > > Have you looked at the number of operations involved in calculating, say, the 1000th term as vs a standard looping 
  35. approach?
  36. > 
  37. >    That's exactly why he was using this as an example.  It is easy to program,
  38. > contains many iterations, and illustrates his point:  recursion is very fast
  39. > in Smalltalk.
  40. > 
  41. > > I don't think this is a valid benchmark... (and I too fail to see how
  42. > > Smalltalk can be faster than C++ except perhaps in bizarre special
  43. > > cases)
  44. > >
  45. > > - /\/\ark \/anTassel (mvantassel@teambca.com)
  46. > 
  47. >    Try his experiment and you will see a set of problems for which the speed of
  48. > Smalltalk compares to that of c/c++.  You may dismiss this set of problems as
  49. > "bizarre", but as the size of that set increases, so does its importance.
  50. > 
  51. >   Many (note that I am not saying all) c/c++ programmers claim that "Smalltalk
  52. > is slow," and therefore dismiss it.  This is wrong for two reasons:
  53. >       1. If speed were the only measure of value we'd all
  54. >          be programming in Assembler (or tuning c compiler-
  55. >          generated Assembler).
  56. >       2. Smalltalk is much faster than many people think.
  57. > 
  58. > The fact is that Smalltalk can do a few things faster than c/c++, and some
  59. > things as fast.  I would also argue that most of the remaining things in
  60. > Smalltalk are not "significantly slower" than c/c++.  This point is debatable
  61. > as it depends upon the requirement of your domain.
  62. > 
  63. > It would be nice if we all had the resources to evaluate each of these
  64. > languages fairly.  Smalltalk is shortchanged if the programmer writes only
  65. > c/c++-style code, just as c++ is shortchanged if the programmer writes only
  66. > c-style code.
  67. > 
  68.  
  69. Isn't it about time you changed the subject of this thread?
  70.  
  71. -- 
  72. Robert Stewart        | My opinions are usually my own.
  73. Datalytics, Inc.    | stew@datalytics.com
  74.